Row hammer monitoring based on stored row hammer threshold value

ABSTRACT

Detection logic of a memory subsystem obtains a threshold for a memory device that indicates a number of accesses within a time window that causes risk of data corruption on a physically adjacent row. The detection logic obtains the threshold from a register that stores configuration information for the memory device, and can be a register on the memory device itself and/or can be an entry of a configuration storage device of a memory module to which the memory device belongs. The detection logic determines whether a number of accesses to a row of the memory device exceeds the threshold. In response to detecting the number of accesses exceeds the threshold, the detection logic can generate a trigger to cause the memory device to perform a refresh targeted to a physically adjacent victim row.

FIELD

Embodiments of the invention are generally related to memory management,and more particularly to monitoring row hammer events based on a stored,programmed value.

COPYRIGHT NOTICE/PERMISSION

Portions of the disclosure of this patent document may contain materialthat is subject to copyright protection. The copyright owner has noobjection to the reproduction by anyone of the patent document or thepatent disclosure as it appears in the Patent and Trademark Officepatent file or records, but otherwise reserves all copyright rightswhatsoever. The copyright notice applies to all data as described below,and in the accompanying drawings hereto, as well as to any softwaredescribed below: Copyright © 2012, Intel Corporation, All RightsReserved.

BACKGROUND

With advances in computing technology, computing devices are smaller andhave much more processing power. Additionally, they include more andmore storage and memory to meet the needs of the programming andcomputing performed on the devices. The shrinking size of the devicestogether with the increased storage capacity is achieved by providingdevices with higher density, where there are more and more atomicstorage units within a memory device, but each has smaller and smallergeometries.

Within the latest generation of increased density devices, intermittentfailure has appeared in some devices. For example, some existing DDR3(dual data-rate, version 3) based systems experience intermittentfailures with heavy workloads. Researchers have traced the failures torepeated access to a single row of memory within the refresh window ofthe memory cell. For example, for a 32 nm process, if a row is accessed550K times or more in the 64 ms refresh window, a physically adjacentwordline to the accessed row has a high probability of experiencing datacorruption. The condition has been referred to as “row hammer” or“single row disturb” in the DRAM (dynamic random access memory)industry, where the condition is most frequently observed, and will beused to describe the condition generally herein. The row hammering cancause migration across the passgate. The leakage and parasitic currentscaused by the repeated access to one row cause data corruption in anon-accessed physically adjacent row.

However, those skilled in the art also understand that memory devicesvary among different generations of devices, among differentmanufacturers of comparable devices, and even among different batcheswithin the same manufacturer. Thus, while heavy workloads have beenobserved to cause intermittent failures, there is no clear definition of“heavy workload” that applies to all devices. Thus, the row hammeringcondition is not clearly defined as a general parameter that applies toall devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The following description includes discussion of figures havingillustrations given by way of example of implementations of embodimentsof the invention. The drawings should be understood by way of example,and not by way of limitation. As used herein, references to one or more“embodiments” are to be understood as describing a particular feature,structure, or characteristic included in at least one implementation ofthe invention. Thus, phrases such as “in one embodiment” or “in analternate embodiment” appearing herein describe various embodiments andimplementations of the invention, and do not necessarily all refer tothe same embodiment. However, they are also not necessarily mutuallyexclusive.

FIG. 1A is a block diagram of an embodiment of a system that monitorsfor a row hammer condition using a programmable row hammer threshold.

FIG. 1B is a block diagram of an embodiment of a system that includescolumn/address information logic and distributed detection logic at amemory device to indicate a detected row hammer event in accordance witha programmable row hammer threshold.

FIG. 2 is a block diagram of an embodiment of a system including rowhammer detection logic, and victim logic at a memory device.

FIG. 3A is a block diagram of an embodiment of a system that monitorsfor a row hammer condition in accordance with a threshold from aconfiguration storage of the memory device.

FIG. 3B is a block diagram of an embodiment of a system that monitorsfor a row hammer condition in accordance with a threshold from aconfiguration storage of a memory module.

FIG. 4 is a flow diagram of an embodiment of a process for detecting arow hammer condition in accordance with a programmable row hammerthreshold.

FIG. 5 is a flow diagram of an embodiment of a process for monitoring arow hammer condition of a memory device.

FIG. 6 is an embodiment of a command truth table supporting a targetedrefresh command.

FIG. 7 is a block diagram of an embodiment of a computing system inwhich row hammer monitoring can be implemented.

FIG. 8 is a block diagram of an embodiment of a mobile device in whichrow hammer monitoring can be implemented.

Descriptions of certain details and implementations follow, including adescription of the figures, which may depict some or all of theembodiments described below, as well as discussing other potentialembodiments or implementations of the inventive concepts presentedherein.

DETAILED DESCRIPTION

As described herein, a memory device includes detection logic thatmonitors for a row hammer event. The detection logic obtains a thresholdfor a memory device that indicates a number of accesses within a timewindow that causes risk of data corruption on a physically adjacent row.The detection logic obtains the threshold from a register that storesconfiguration information for the memory device, and can be a registeron the memory device itself and/or can be an entry of a configurationstorage device of a memory module to which the memory device belongs.The detection logic determines whether a number of accesses to a row ofthe memory device exceeds the threshold. In response to detecting thenumber of accesses exceeds the threshold, the detection logic cangenerate a trigger to cause the memory device to perform a refreshtargeted to a physically adjacent victim row.

One approach previously identified to deal with failure due to rowhammer is to limit the number of accesses allowed per row per refreshcycle, which has performance impacts in the system. Another approachidentified to address row hammer failure includes decreasing the bottomcritical dimension (BCD) in the buried channel array transistor (BCAT),and/or increasing channel length to improve the drain induced barrierlowering (DIBL). However, changing the dimension sizes of the deviceshas both physical and practical limitations. To the extent certaindimensions may now be changed, it would still require changes to themanufacturing processes. Also, it leaves open the question of how toaddress the issue in next-generation products.

Another approach to dealing with the row hammer issue is to decrease thetime between refreshes. However, the refresh time has already been heldconstant even as the density of the devices has increased. Currentdevices are required to perform refresh on larger and larger areas inthe same period of time. Thus, further decreasing the refresh time wouldcause a performance impact in the system, such as by requiringadditional refresh overhead in the memory devices.

While these currently proposed approaches for dealing with row hammeringhave negative performance impacts, it is not even clear what processingchanges would need to be made, or how much refresh time would need to bechanged to generally resolve row hammering. Memory controllermanufacturers and memory device manufacturers are generally not the sameentity. Most memory controller manufacturers would like to makecontrollers that can interface with memory devices from different devicemanufacturers. However, currently proposed approaches would fix a memorycontroller to a specific batch of memory devices from a singlemanufacturer, or else would still risk row hammering.

Instead of making design changes or changes to operating parameters ofthe memory devices, the system as described herein can provide an activeruntime mechanism to monitor and address row hammer events. Themonitoring can be actively performed in accordance with a programmedconfiguration value or other threshold value stored in a memory deviceand/or stored on a memory module that includes multiple memory devices.In one embodiment, the memory controller monitors each access to amemory device to determine if the number of accesses to any row causes arow hammer condition. Alternatively, monitoring logic can be distributedto a memory device and/or memory module. Wherever the monitoringmechanism is located, it performs monitoring in accordance with a storedthreshold value obtained from a storage location. When a row hammercondition is detected based on the obtained threshold value, thedetection logic can trigger a row hammer refresh or targeted refresh, asdescribed in more detail below.

The storing of the row hammer threshold recognizes the fact that rowhammer limits will vary across memory device suppliers, and also acrossdifferent batches within the same supplier or manufacturer.Additionally, memory devices have historically moved to new processtechnology which increases the density of the memory devices. There isno reason to believe that trend will stop in the near future. Seeingthat the row hammer condition is a memory density issue, the move to newprocess technology will also change the row hammer limit or threshold ofmemory devices. It is common to replace memory devices with newerdevices, which for any of the reasons above can have a different rowhammer event threshold. Storing the threshold and using that in themonitoring enables a memory subsystem to track row hammering specific tothe devices present in the memory subsystem.

Thus, memory controllers can track the number of accesses to the rows(tracking row hammering) and issue a command to the memory devices torefresh targeted adjacent rows. In one embodiment, the thresholdinformation is stored in a register on the memory device (e.g., DRAM)itself. Such information can be fused by the manufacturer or a devicetester, for example. In one embodiment, the value is stored as a fieldin a configuration register, which is written to the specific memorydevice, or written to a memory module (e.g., a DIMM (dual inline memorymodule) after determining its characteristics.

It will be understood that the storing of the information can beperformed in any of a number of different ways. In one embodiment, theinformation is encoded in the device and/or memory module. For example,a three-bit code can be used to provide threshold limits. The encodingcan be established any way agreed upon by memory controller suppliers,memory device suppliers, a different, third party, or some combination.Examples follow of different ways the encoding could be configured.Encoding Example 1: 000-no limit; 001-500K; 010-400K; 011-300K;100-250K; 101-200K; 110-150K; 111-100K. Example 2: 000-100K or notdefined; 001-150K; 010-200K; 011-250K; 100-300K; 101-400K; 110-450K+;111-unknown RH limit. Those of skill in the art will understand thereare practically innumerable variations on the specific values used inthese examples. Thus, these examples are meant to illustrate encoding,but are not to be understood as limiting.

The examples provided herein primarily discuss the row hammer issue withrespect to DRAM. However, it will be understood that the row hammerissue is more generally a memory device scaling issue, which occurs asmemory densities increase. Thus, the descriptions with respect to DRAMwill be understood as non-limiting examples that can be applied to othermemory technologies that include memory controller or equivalent logic.The targeted refresh command described herein is compatible with any ofa number of memory technologies, such as DDR4 (dual data rate version 4,specification in development as of the filing of this application),LPDDR4 (low power dual data rate version 4, specification in developmentas of the filing of this application), or WIDEIO (specification indevelopment as of the filing of this application). The storing of rowhammer condition limit information is likewise compatible with anymemory technology where the memory device can store configurationinformation on itself, and/or where a memory module stores configurationinformation.

FIG. 1A is a block diagram of an embodiment of a system that monitorsfor a row hammer condition using a programmable row hammer threshold. Inone embodiment, the use of a stored threshold can be referred to as aprogrammable row hammer threshold. System 100 includes memory device 110coupled to memory controller 120. Memory device 110 can include any typeof memory technology that has adjacent rows of memory cells, where datais accessible via a wordline or the equivalent. In one embodiment,memory device 110 includes dynamic random access memory (DRAM)technology.

Memory device 110 includes memory array 112, which represents one ormore logical and/or physical groups of memory (which can include ranks,banks, and/or other groupings). While not specifically shown in system100, memory array 112 can include one or more rows that are the targetsof repeated access within a time window. Such a row is subject to a rowhammer condition. In many modern memory devices, the architecture of thesemiconductor layout causes one or more physically adjacent rows to beat risk of becoming corrupted. The row or rows at risk of becomingcorrupted due to row hammer condition are referred to herein as victimrows.

Memory device 110 includes column logic 114 and row logic 116, which areused to decode an access instruction to the proper memory locationwithin memory array(s) 112. There is no requirement for the number ofrows and columns to be equal, and in fact they are typically not equal.Memory controller 120 sends commands or instructions to memory device110 over a command bus (e.g., a command/address (C/A) bus), which arethen interpreted by memory device 110. Memory device 110 decodes thecommand information to perform a variety of access functions within thememory, and decodes address information via column logic 114 and rowlogic 116. The logic accesses a specific location in memory with acombination of a column address strobe or signal (CAS) and a row addressstrobe or signal (RAS). Rows of memory can be implemented in accordancewith known memory architectures or their derivatives. Briefly, a row ofmemory includes one or more addressable columns of memory cells, asidentified by the CAS generated by column logic 114. The rows areaddressable via the RAS generated by row logic 116.

In one embodiment, memory device include configuration 118. In oneembodiment, configuration 118 is stored within memory device 118.Alternatively, configuration 118 represents configuration associatedwith memory device 110, which is stored somewhere other than in memorydevice 110. Configuration 118 can be stored in a register device orother storage device within the memory device.

System 100 includes detector 130, which represents hardware and/orsoftware or other logic that enables system 100 to detect a row hammerevent or row hammer condition. There can be multiple differentmechanisms used to detect the row hammer condition. System 100 detects arow hammer condition via detector 130, which in one embodiment includesa table or log to monitor accesses to selected rows of memory. Thus,detector 130 can determine when a row of memory array 112 experiencesrepeated accesses within a threshold time period. Detector 130 caninclude hardware and/or logic at memory device 110, memory controller120, and/or separate from either the memory device or the memorycontroller.

Detector 130 determines a number of times a row is accessed within atime period. Detector accesses or otherwise obtains row hammer thresholdinformation from configuration 118. A row hammer event is not simplyabout how many times a row is accessed, but how many times in a giventime period. Once a row is refreshed, the conditions that could causedata corruption are overcome. Thus, the time period for the monitoringcan be based at least in part on the refresh rate. In one embodiment,the time period during for which detector 130 monitors for a thresholdnumber of accesses is equal to the refresh cycle time of memory device110. The number of accesses during the time period is determined fromconfiguration 118.

In one embodiment, memory controller 120 generates targeted refreshcommand 122 to cause the memory controller to perform a targeted refreshin response to detecting a row hammer event. Targeted refresh command122 is a refresh command that occurs “off-schedule,” meaning that thecommand is sent in response to detecting the row hammer event as opposedto sending the command because a timer indicates it is time to perform arefresh. In one embodiment, memory controller 120 doubles up an existingcommand to send a targeted refresh command. For example, targetedrefresh command 122 could be doubled up with either an Activate or aRefresh command as defined for DRAM (dynamic random access memory). Thememory controller can accomplish the doubling up, for example, by use ofanother pin and/or a Mode Register state that can cause the memorydevice to interpret a command as a targeted refresh instead of theActivate or (standard) Refresh commands. Memory controller 120 providesaddress information to indicate the hammered row. Detector 130 canindicate address information identifying the row, which memorycontroller 120 can indicate to memory device 110 to cause the memorydevice to determine what victim row(s) should be refreshed. The addresscan be indicated to the memory device specifically, or can be providedmore generally. Thus, when detector 130 determines that a specific rowof memory is subject to a row hammer condition (accesses have reached orexceeded a threshold), it indicates the row to memory controller 120,which in turn can send a targeted refresh command.

When referring to targeted refresh command 122, it will be understoodthat different memory device manufacturers use different logic andarchitectures to utilize the memory resources of the devices. Forexample, different memory device manufacturers can use different offsetsto map between logical memory addresses used in the host processor (notshown) and the physical memory addresses used internally to memorydevice 110. In one embodiment, memory controller 120 utilizes the samelogical memory addresses as used by the host processor. Thus, in oneembodiment, memory controller 120 provides a row address to memorydevice 110 indicating the hammered row. The memory controller canindicate the row address in conjunction with and/or as part of a commandthat it issues to memory device 110. The memory device can then computethe specific address or addresses of any victim row(s). Memory device110 then performs a targeted refresh on the physically adjacent, victimrow(s).

In one embodiment, detector 130 includes configuration to set thetimeframe for which it is to monitor for a row hammer condition, as wellas configuration to set the number of accesses that define a row hammerevent that would cause the memory controller to trigger a targetedrefresh, based on information obtained for the specific memory devices.Detector 130 maintains data for a subset of the total number of rows insystem 100. In one embodiment, detector 130 maintains data for a numberof rows based on MVC, which is the maximum victim count expected for theconfigured timeframe. For example, detector 130 can keep a table withMVC+1 entries, or more entries. Detector 130 can then roll entries intothe table for memory locations that are accessed, rolling out thelowest-count entries in the table to replace them.

It will be understood that the described threshold could also bedescribed as an access rate threshold referring to the rate of access tothe memory rows that causes the row hammer condition, a row hammerthreshold referring to the threshold at which a row hammer condition canbe detected to exist, or a row hammer limit referring to a limit to anumber of accesses within a window that represents a point at which therisk of data corruption exists. Other expressions could also be usedreferring to the fact that a number of accesses detected within a timewindow can be addressed by the system to avoid data corruption.

FIG. 1B is a block diagram of an embodiment of a system that includescolumn/address information logic and distributed detection logic at amemory device to indicate a detected row hammer event in accordance witha programmable row hammer threshold. System 150 is a system thatincludes a memory device or memory subsystem and a memory controller inaccordance with any embodiment described herein. System 150 includesmemory device 110 coupled to memory controller 120. Memory device 110can include any type of memory technology that has adjacent rows ofmemory cells, where data is accessible via a wordline or the equivalent.

Memory device 110 includes memory array 112, which represents one ormore logical and/or physical groups of memory. In one embodiment, memorydevice 110 includes C/A logic 166, which is used to decode accessinstructions to specific memory location(s) within memory array 112. C/Alogic 166 includes decode logic 168 such as column logic and row logic,which activate memory locations for reading and/or writing. C/A logic166 can be implemented as a C/A register (e.g., of an RDIMM or LRDIMMdevice), as a C/A buffer or other logic buffer (e.g., in a 3DS(three-dimensional stacking) configuration or buffer-on-boardsimplementation), or other logic device. In one embodiment, C/A logic 166is implemented as a logic buffer in a three-dimensional stacked memorydevice, such as a hybrid memory cube (HMC), where DRAM devices arestacked on top of the logic buffer.

Memory controller 120 sends commands or instructions (C/A info 124) tomemory device 110 over a command bus (e.g., a command/address (C/A)bus), which are then interpreted by memory device 110. Memory device 110decodes the command information to perform a variety of access functionswithin the memory, and decodes address information via decode logic 168.The logic accesses a specific location in memory with a combination of acolumn address strobe or signal (CAS) and a row address strobe or signal(RAS). Rows of memory can be implemented in accordance with known memoryarchitectures or their derivatives. Briefly, a row of memory includesone or more addressable columns of memory cells, as identified by theCAS. The rows are addressable via the RAS.

In one embodiment, memory device 110 includes detector 164, whichrepresents hardware and/or software or other logic that enables memorydevice 110 to detect a row hammer event or row hammer condition. In oneembodiment, detector 164 is included within C/A logic 166. In eithercases detector 164 can be said to be distributed in that it includeslogic at memory device 110 to monitor for row hammer conditions. Rowhammer event detection can be performed by array, device, rank, or otherseparation of the memory resources.

There can be multiple different mechanisms used to detect the row hammercondition. Detector 164 can include a table or log to monitor accessesto selected rows of memory. When memory device 110 includes detectorlogic, detector 164 can monitor for row hammer conditions based onthreshold information stored in configuration 118. When a row hammerevent or row hammer condition is detected, in one embodiment, C/A logic166 generates alert signal 126 to indicate the condition to memorycontroller 120. In response to the alert, memory controller 120 triggersa targeted refresh in response to detecting a row hammer event, inaccordance with any embodiment described herein.

FIG. 2 is a block diagram of an embodiment of a system including rowhammer detection logic, and victim logic at a memory device. System 200can be one example of a memory subsystem in accordance with anyembodiment described herein. System 200 illustrates one logicalunderstanding of a memory subsystem. DRAM 210 includes rows of memory inmemory 212, which are rows of memory in accordance with known memoryarchitectures or their derivatives. Briefly, a row of memory includesone or more addressable columns of memory cells. In one embodiment, DRAM210 map logical address information from memory controller 230 tophysical memory locations in memory 212.

It is understood that memory is typically accessed in such a way that“adjacent” memory addresses provided by memory controller 230 (typicallylogical addresses) do not necessarily map to physically adjacent memorylocations in DRAM 210. Rather, each adjacent memory address as providedby memory controller 230 maps to addresses that are located as someconsistent offset. Some memory devices scramble the address, thusresulting in victim rows that are identified at the memory device itselfby descrambling the address information. For example, addresses 0xX0h,0xX1h, and 0xX2h could be located at physical locations 0xY0h, 0xY3h,and 0xY7h, respectively, where the offset is ‘4’. In the example, ‘X’represents the higher bit information of the addresses as provided bythe memory controller, and ‘Y’ represents the higher bit information ofthe addresses as mapped within DRAM 210. Thus, the memory device itselfcan determine the victim row based on the configuration of the device inconjunction with the address information provided by the memorycontroller with a targeted refresh command.

Host processor 240 can be any type of processing unit, processor,central processing unit (CPU), graphics processing unit (GPU),microcontroller, or other processing device. Host processor 240generally accesses DRAM 210 and other memory devices via memorycontroller 230. In one embodiment, memory controller 230 is part of hostprocessor 240 or a processor package of host processor 240. In analternate embodiment, memory controller 230 is part of a supporting“chipset” or hardware logic that provides an infrastructure for powerand interface logic for a hardware platform of which host processor 240is a part. In one embodiment, DRAM 210 is a volatile memory, or a memorydevice whose contents are non-deterministic if power is interrupted tothe device. Thus, a volatile memory requires a regular power source toallow it to refresh the memory cells to keep the data from become lostor corrupted. As mentioned above, detection logic 234 enables system 200to identify a row hammer condition to be able to respond to the rowhammer condition with a targeted refresh.

DRAM 210 includes victim logic 214, which represents logic to determinewhat row or rows are at risk of corruption due to the row hammercondition. In one embodiment, victim logic 214 can be at least partiallyexecuted at memory controller 230. However, for the sake of broaderinteroperability between memory controller 230 and other types of memorydevices, victim logic 214 generally resides at DRAM 210. Thus, memorycontroller 230 need only provide a targeted refresh trigger to DRAM 210to cause a targeted refresh. DRAM 210 can use a map or other logic todetermine what row or rows are potential victims.

DRAM 210 includes control logic 216, which includes logic to performrefresh of memory 212. Each memory device includes some logic to keeptrack of what memory cells have been refreshed, and what rows are nextdue for a refresh. Control logic 216 can implement the actual targetedrefresh based on receiving a targeted refresh command.

DRAM 210 can include one or more registers 218, which allow forconfiguration of DRAM 210 and/or communication between DRAM 210 andmemory controller 230. In one embodiment, a register 218 storesthreshold information that indicates a number of accesses that representa row hammer condition. Memory controller 230 includes command logic232. Command logic 232 enables memory controller 230 to read and/orwrite registers 218. In one embodiment, memory controller 230 triggers atargeted refresh by setting a value in a register 218 of DRAM 210 tocause the memory device to perform the targeted refresh. In oneembodiment, memory controller 230 triggers the targeted refresh inresponse to detecting that a number of accesses to a row exceeds athreshold read from register 218. Detection logic 234 represents logicin accordance with any embodiment described herein that enables memorycontroller 230 to determine that the number of accesses to a row exceedsthe threshold read from register 218.

FIG. 3A is a block diagram of an embodiment of a system that monitorsfor a row hammer condition in accordance with a threshold from aconfiguration storage of the memory device. System 302 represents anexample of a system that includes a memory subsystem with memorycontroller 330, memory device 320, and detector 310. System 302 providesone example of a system in accordance with systems 100, 150, or 200described above. In one embodiment, detector 310 is part of memorycontroller 330. Memory controller 330 can issue a targeted refreshcommand in response to detection of a row hammer condition by detector310.

Memory device 320 includes multiple rows of memory. Among the rows istarget row 322, which is a row that is the target of repeated accesswithin a time period. Victim row 324 is a row that is at risk of datacorruption due to the hammering of target row 322. There can be morethan one victim row associated with a hammered row (e.g., each rowphysically adjacent to the hammered row). In one embodiment, memorydevice 320 includes configuration 340 that indicates a specific valuedetermined for the memory device to represent a row hammer or accessrate threshold. The row hammer threshold can be determined by amanufacturer.

In one embodiment, detector 310 includes access log 312. Access log 312can be implemented as a list or array or table or other logicalstructure that stores entries having multiple fields of information.Each entry includes at least an address or identifier for a specific rowof memory and an access count for the entry. The number of entries inaccess log 312 is much smaller than the total number of rows in memorydevice 320. Thus, detector 310 can monitor by keeping a count for asubset of all rows. The count of each row can be incremented as the rowis accessed again, and the count can be compared to the threshold todetermine if the row has been accessed the threshold number of times.

Detection logic 314 includes logic to enable detector 310 to determinethat an access command is directed to a row of memory. While detectionlogic 314 is shown specifically with a line to target row 322, detectionlogic 314 can monitor accesses to any row in accordance with the rowhammer threshold set out in configuration or configuration information340. In one embodiment, detection logic 314 includes a mechanism todetermine an address of an Activate command issued by memory controller330. Thus, every time memory controller 330 sends a command for memorydevice 320 to activate a row of memory, detector 310 can identify theaddress associated with the command, and keep track of access for theaddress in access log 312.

Detector 310 determines when access to a row exceeds a threshold, andindicates the row address information to the memory controller. It willbe understood that the address information in access log 312 is notnecessarily the same address used by memory device 320 to access thephysical memory resources. Memory device 320 decodes the addresses sentby memory controller 330 to physical resources. Thus, when detector 310identifies a row for which accesses have reach or exceeded thethreshold, the information may still need to be decoded to identifyphysical resources of target row 322 so that physically adjacent victimrow 324 can be identified.

Detector 310 receives timer information 316, through which detector 310can identify the start of a timeframe or time period or time window, aswell as the end of a timeframe. The monitoring takes place between thebeginning and end of the timeframe. In one embodiment, the timeframegoes from one scheduled refresh to the next.

In one embodiment, detector 310 clears the count of an entry in accesslog 312 when the count of the entry reaches the threshold and isidentified to the memory controller. It will be understood thatdetection can be performed on a rank and/or bank granularity. There isnot necessarily a single detector 310 for the memory controller. Eachbank can be tracked, and each memory channel can have monitoring.

FIG. 3B is a block diagram of an embodiment of a system that monitorsfor a row hammer condition in accordance with a threshold from aconfiguration storage of a memory module. System 304 illustrates oneexample of an embodiment of system 302 or any other memory subsystemdescribed herein. Whereas system 302 illustrated a single memory device320, system 304 illustrates memory module 350, which includes multiplememory devices 320. In some systems, a memory device is disposeddirectly onto a motherboard or primary circuit board of a host device.System 302 represents a memory subsystem where memory device 320 isplaced directly on a host system board. System 304 represents the use ofa module board that typically connects to a host system board via aconnector. The descriptions with respect to memory controller 330,detector 310, access log 312, detection logic 314, and timer 316 insystem 302 apply equally well to system 304.

Memory module 350 includes multiple memory devices 320, and adistributed detector 354 can be included on memory module 350. In oneembodiment, memory module 350 includes a configuration device,represented by configuration 352. In one embodiment, configuration orconfiguration information 352 is included in a serial presence detect(SPD) device, which is commonly used on DIMMs, or comparable moduledevice.

Typically the SPD is a small serial EEPROM (electronically erasableprogrammable read only memory) or flash device mounted on the memorymodule which contains data related to size, speed, architecture details,and/or other manufacturing data. Generally a memory manufacturer ortester or other subcontractor programs the SPD during themanufacturing/verification process. Memory controller 330 and/ordetector 310 can read the data from configuration 352. Thus, a memorysupplier can program information for the entire group of memory devices320 on memory module 350.

In one embodiment, each memory device 320 includes configuration orconfiguration information 340 in addition to memory module 350 storingconfiguration 352. It is possible to have variation in differentdevices, where one device operates according to one threshold, andanother to another threshold. The SPD can have a worst-case value savedto it, and each device (e.g., in an MPR) can store a device-specificvalue, for example. The memory controller can track module by module(e.g., DIMM by DIMM), or by lowest threshold.

It will be understood that one or more memory device 320 on memorymodule 350 could have different threshold values. In one embodiment,detector 310 monitors for row hammer conditions based on individualconfiguration information 340 from configuration registers of individualmemory devices 320. Such an embodiment can include implementations whereconfiguration 352 exists for the memory module. Alternatively, detector310 can monitor based on configuration 352 despite each memory device320 including individual configuration 340. In one embodiment, detector310 monitors based on individual configuration 340 unless there is aconflict (i.e., different threshold values), in which case it willmonitor based on configuration 352.

In one embodiment, threshold configuration 352 on memory module 350stores the most restrictive threshold, or the lower threshold, of anymemory device 320. Memory module 350 can include logic to make such adetermination and store the value. Alternatively, memory controller 330could read threshold from configuration devices of each memory device320 and write the threshold information into configuration 352. In oneembodiment, the row hammer threshold information is simply one field ofconfiguration 352 and/or of configuration information 340. In oneembodiment, configuration 340 is stored in Page 3 of a multi-purposeregister (MPR) or each storage device 320, which can be used forvendor-specific information. Thus, different thresholds due to differentlots, processes, suppliers of memory devices 320 can be effectivelytracked in systems 302 and 304.

FIG. 4 is a flow diagram of an embodiment of a process for detecting arow hammer condition in accordance with a programmable row hammerthreshold. A supplier manufactures a memory device, 402. A memory devicein this context can refer to a discrete memory die in its packaging(e.g., a memory “chip”). The supplier or another party that receives themanufactured memory chip determines a row hammer threshold for thememory device, 404. The determining can include making a determinationbased on knowledge of the processes used and conditions existent duringmanufacture of the memory device, and/or through the performing of oneor more tests on the device.

The supplier or other party can program the row hammer threshold into amemory device configuration register, 406. The threshold is notnecessarily placed on the memory device itself. In one embodiment, thememory device is placed on a module with other memory devices, 408. Whenused in a memory module, different memory devices can be placed on themodule at different times. Similarly, different memory modules can beplaced at separate times on a memory bus of a host computer system. Ineither case, there could be a mismatch of threshold among memory devicesand/or among memory modules. In one embodiment, row hammer conditionsare monitored on a device-by-device basis based on their own thresholdinformation. In one embodiment, different memory modules are monitoredbased on different thresholds. In one embodiment, all memory devices ina system are monitored in accordance with a single threshold value,which then is typically set to be the lowest threshold of any device inthe memory subsystem.

Thus, either a memory supplier or a memory module supplier can program amemory module row hammer threshold based on the devices in the memorymodule, 410. In one embodiment, a host system (e.g., via the memorycontroller or other logic), detects and programs the memory module rowhammer threshold. In one embodiment, the memory module self-discoversits row hammer threshold.

In an active system with the memory device and/or memory module,detection logic monitors the memory device for a row hammer condition asdefined by a row hammer threshold associated with or applicable to thememory device, 412. A threshold is associated with or applicable to amemory device if it is stored on the device itself, or on a memorymodule of which it is a part, or otherwise obtained and used by thedetection logic to monitor it. Thus, the detection logic obtains thethreshold for the memory device, 414, and determines whether the numberof accesses to row(s) of the memory device exceed the threshold, 416.

If the threshold is exceeded, 418 NO branch, the detection logiccontinues to monitor for a row hammer condition, 412. If the thresholdis exceeded, 418 YES branch, the detection logic generates a trigger tocause a targeted refresh of the memory device, 420. The trigger can bein accordance with any embodiment described herein.

FIG. 5 is a flow diagram of an embodiment of a process for monitoring arow hammer condition of a memory device. The memory device anddistributed detection logic can use any mechanism to monitor for rowhammer conditions that would indicate when accesses to a row of memoryhave increased the likelihood of corruption in a victim row beyond whatis configured as an acceptable level. Some mechanisms can includekeeping a count for only a subset of all rows, instead of keeping acount for all rows. Some mechanisms maintain a table, which couldinclude an ordered table of accesses. Some mechanisms can be based on acomputed maximum victim count (MVC). One implementation is described asfollows.

An administrator can configure a memory subsystem with a row hammermonitor time window or timeframe, and a threshold value of accesses thatindicates a row hammer condition, 502. The administrator canpre-configure the system to receive inputs that indicate the timeframeand threshold values. In one embodiment, the configuring is part ofsetting register values or configuration in firmware for the memorysubsystem. The system includes a detector or detection logic configuredto perform monitoring for the timeframe, monitoring for the thresholdnumber of accesses. Additionally, as described herein, the specificthreshold value is obtained for a memory device or group of memorydevices (e.g., a module).

Thus, the timeframe and number of accesses are defined in the system. Inone embodiment, the timeframe is 64 milliseconds. The number of accessesthat make up the threshold depend on the architecture of the memorydevice to which the memory controller is connected, including the sizeof the memory and the density of the memory (e.g., the minimum processfeature size). The number of accesses that indicate a row hammer eventcan be somewhere in the range of 150K to 550K accesses during the timewindow. Such information is stored in a memory location (e.g., register)of the memory device and/or memory module.

The memory controller or detector can compute the maximum number ofvictim rows that are possible in the system, 504. The operationsdescribed below could be considered to be performed by the detector orthe memory controller, depending on the implementation. For simplicityin description, the below description refers to operations by thedetector, but will be understood as being able to be performed by eitherthe detector, or the memory controller, or both, or that the detectorcan be part of the memory controller. The administrator couldalternatively compute the maximum number of victim rows. The computationis based on determining what the maximum number of rows is that could beaccessed the threshold number of times in the timeframe. As one simpleexample, consider a system in which the number of accesses that definesthe threshold is 250K, and the timeframe is 64 ms. If each access takessomewhere on the order of 10 ns, then the maximum number of victim rowsis approximated by 26 (64 ms/(250K*10 ns)=25.6). The maximum number ofvictims can be referred to as MVC (maximum victim count). It will beobserved that this number of orders of magnitude smaller than the simplecase of monitoring each row individually.

In one embodiment, the detector builds an array of entries based on thevalue of MVC, 506. The array can be a table or log or other structure.In one embodiment, the number of entries is at least MVC+1. The numberof entries could be some multiple of MVC. In one embodiment, each entryof the table or log includes a row address accessible by CAM (contentaddressable memory) and an access count value. It will be understoodthat CAM allows access based on comparison of addresses. Otherinformation could also be included in the entries.

In one embodiment, the detector initializes the array at the start ofthe timeframe, 508. The initialization can include a number of differentoperations. In one embodiment, on the start of a timeframe, the detectorinitializes each entry of the array to non-valid (e.g., by setting aflag or entering a value in the entry, or keeping a bitmap of validentries separate from the array). In one embodiment, the detector resetsthe count value of each entry to zero.

In one embodiment, the detector can monitor each row by activation thatidentifies the row in the address fields of the Activate command (e.g.,using CAM), 510. In one embodiment, the detector sorts the array byorder of counter values (e.g., highest to lowest or lowest to highest).The sorting of the array can be accomplished by a sort, linked list, orother mechanism.

For every new activation of a row detected by the detector, 512, thedetector can determine if the row is already in the array, 514. If therow is in the array, 514 YES branch, the detector increments the countfor that entry, 516. There can be an additional requirement of havingthe entry also be valid (thus, increment if the row is in the array, andthe entry is valid). There can be many ways of dealing with thesituation where a row is not already in the array, 514 NO branch. In oneembodiment, the detector determines if there are empty entries orinvalid entries available in the array, 518.

If there is an available entry in the array, 518 YES branch, thedetector fills the entry with the information associated with the rowfor which an activation was detected, 520. As needed for the specificimplementation, the detector can also mark the entry as valid. Thedetector then increments the count for the entry, 516.

If there is not an available entry in the array, 518 NO branch, thedetector can replace the entry with the lowest access count value withthe row address of the row for which the activation was detected. 522.In one embodiment, the access count in the entry is specifically notreset or zeroed. Rather, the address information for the entry isreplaced for the row that was just activated. It will be understood thatcertain rows in memory could be repeatedly accessed, but the repeatedaccess could dither back and forth with access to another entry. Thus,by keeping the access count and incrementing it, it is almost certainlyhigher than the number of accesses for the row, but it will never belower than the true number of accesses.

Thus, the detector keeps the previous access count value or row count,and increments it, 516. It will be understood that the simplest form ofincrementing is by increasing the row count by 1 each time, but otherforms of incrementing could be used. After incrementing, 516, thedetector determines if the row count is at the maximum count, or whetherthe row has reached the threshold, 524. In one embodiment, the detectorchecks to see if the threshold is reached every time it detects a rowactivation, but other implementations are possible. In particular, fornewly added entries, there may be no need to check the count against thethreshold.

Regardless of the implementation, when the detector determines if therow is at the threshold, it can issue a targeted refresh command for therow to address the row hammer condition. If the row has not reached thethreshold, 524 NO branch, the detector keeps monitoring, 510. If the rowhas reached the threshold, 524 YES branch, the detector indicates theaddress information of the row to the memory controller for thetriggering of a targeted refresh command, 526. In one embodiment, whenan entry reaches the threshold, the detector also resets the smallestcount value of the entry to the smallest count value of any entry in thearray. Again, such an action prevents the array from losing countinformation for an entry that is being repeatedly accessed, but at leastinitially is not being accessed as frequently as other rows. Thedetector can also clear the valid bit of the entry.

It will be understood that the operations described herein tend to“float up” the most frequently access rows. When implemented asdescribed, there should not ever be a circumstance where there is a rowwhose actual access count is larger than the smallest access count ofany entry in the array or list. Additionally, the risk of false alarmsis limited due to the fact that the number of rows causing the targetrefresh cannot exceed the value of MVC.

Embodiments are described above with specific reference to the Figures.In general, it will be understood that various modifications of thesystem can be made. In one embodiment, row hammer detection logic is onthe memory device itself. For example, the memory device can includedetection logic in a device that handles the command and addressinformation coming into the memory device. For example, a C/A(command/address) register or buffer or other comparable device on anRDIMM (register DIMM) or LRDIMM (load reduction DIMM). In oneembodiment, the system performs distributed monitoring or distributedtracking via such a C/A device, or other distributed logic. The logiccan use any method to monitor and/or track accesses to portions of thememory, such as what is described below with respect to FIG. 5, or anyother method.

In one embodiment, the detection logic can be distributed acrossmultiple logical portions of the memory device. Thus, even if alldetection logic is executed in a C/A device, it can be considereddistributed logic for purposes herein if it can monitor across differentlogical portions, each portion individually. The detection logic in thememory device alerts the memory controller when a row hammer event isdetected. In one embodiment, the alert is triggered via a pulse width onan alert pin (e.g., ALERT#). In one embodiment, the memory devicetriggers the alert via setting the alert pin, and waiting for the memorycontroller to reset the alert pin. The memory controller can also pollthe memory device in response to an alert to determine what alert isbeing indicated. In that way, multiple alerts could be generated on thesame alert pin. Thus, for example, in current DDR DRAM designs, the hostor the memory controller could differentiate between C/A parity errorindication (asserted by a pulse width) and row hammer event indicationif the row hammer event indication is indicated either as a setting ofthe pin, or if it pulses the pin and awaits a poll.

In one embodiment, the memory controller configures the memory device todetect row hammer events. For example, the memory controller can programthe threshold values for what number of accesses triggers a row hammerevent in a register control word. In one embodiment, the memorycontroller programs a time window for the memory device to determine rowhammer conditions. For example, in some memory subsystems, a time windowdifferent than the refresh window could be used. In other subsystems,the refresh window could be programmable. If the threshold of number ofaccesses is reached in the given time window, the memory device (e.g.,via a C/A register device) sends the alert signal to the host (e.g., tothe memory controller).

When the memory controller receives an indication of a row hammercondition from the memory device, the memory controller triggers atargeted refresh in the memory device for a victim row for the rowhammer condition. There are many alternatives to how the memorycontroller can trigger the targeted refresh. In one embodiment, thememory controller issues a row hammer refresh command to the memorydevice and indicates an address that triggered the row hammer condition.The memory controller can obtain the address from the C/A device in thememory device (e.g., via reading a control word). The memory controllercan specify an exact address of the row that caused the row hammercondition and allow the memory device to resolve what row(s) arevictim(s) (or physically adjacent). Alternatively, the memory controllercould determine the specific victim row address. The memory controllercan send an address that identifies a region of memory instead of theexact location of the row that triggered the row hammer condition.

In one embodiment, the memory controller issues a trigger to cause thememory device to generate a row hammer command. For example, the memorycontroller can write to a control bit in a C/A device, which can in turngenerate a row hammer refresh command. Such a trigger would require lessprocessing on the part of the memory controller, but more processing bythe memory device. However, if the memory device has detected the rowhammer event, it should have the address of the row that caused the rowhammer event, and so could issue the command without having to exchangethe address back and forth between the memory device and memorycontroller. In an alternative embodiment, the memory controller issues arow hammer refresh command (also referred to as a targeted refreshcommand) without including address information. The memory device (e.g.,via the C/A device) can provide the address information and forward thecommand to the memory resources that will execute the targeted refresh.

It will be understood that reference to a C/A device is non-limiting.The distributed row hammer event management can be implemented in a C/Aregister of an RDIMM subsystem, a C/A register of an LRDIMM subsystem, abuffer of a buffer-on-boards (BoB) implementation, a logic buffer devicein a 3DS (three-dimensional stacking) configuration, or some otherdevice that handles command and address information.

As mentioned above, the memory controller can send a targeted refreshtrigger that does or does not include address information. The addressinformation can indicate what row is getting hammered, and thus not haveto directly indicate the victim row (or the target of the targetedrefresh command). In a typical refresh scenario, the memory deviceitself tracks what needs to be refreshed when. Thus, the memory deviceitself can calculate what victim row or rows will be affected by the rowhammer event based on the memory layout used by the memory device. Thememory device refreshes the victim row(s) by opening the row and thenclosing the row(s) to refresh.

It will be understood that for the memory controller to indicate anaddress of the hammered row to cause the memory device to refresh victimrow(s) of the hammered row requires a certain number of bits to identifya specific address. In one embodiment, the memory controller identifiesa specific address. In another embodiment, the memory controlleridentifies an area larger than a specific row. Thus, a memory controllercan identify a specific block, a specific row, or an area, depending onthe chosen configuration. The cost of identifying a very specificaddress is the number of bits required. The cost of identifying theaddress more generally is that the memory device needs to refresh alarger area, making the memory device unavailable for a longer refreshtime.

In one embodiment, the memory controller indicates address informationby sending address information to the memory device. In one embodiment,one or more additional pins or lines can be added between the memorycontroller and the memory device embeds address information into anexisting command to identify address information. Thus, the targetedrefresh command can be a modified existing command and/or a modifiedexisting command in conjunction with the use of one or more additionalpins or lines. In one embodiment, the targeted refresh command includessending a command and address multiple times (e.g., three times). In oneembodiment, the address can be modified in the successive commands(e.g., sending the address+1 and then the address−1 in two successivecommands). Other embodiments are possible. In one embodiment, the memorycontroller sends a targeted refresh command, which the memory deviceseparates into one or more groups of Activate and Precharge commands.Other commands could be doubled-up for targeted refresh purposes.

The theoretical maximum number of times a row can be accessed within a64 ms window (e.g., a refresh window) is 1.35 million times (64 msrefresh window divided by 47 ns access time) for current DRAMs (dynamicrandom access memory). The practical maximum without risking datacorruption in the victim rows is much lower, and depends on the processtechnology used. However, by detecting a row hammer event and sending atargeted refresh command, the risk of data corruption can be reducedwithout restricting access to a specific row of memory.

In a memory device, rows that are physically adjacent can often belogically labeled differently from one manufacturer to another.Typically a manufacturer maps logically adjacent rows of memory by aphysical address offset, and the offsets can be different amongdifferent manufacturers. The memory device itself is configured todetermine how to map access requests to the physical memory resources.Memory controllers are generally designed to be compatible with manydifferent types of memory devices, and so they are generally notdesigned specifically with respect to any particular manufacturer'sdevice. Thus, memory controllers do not traditionally have logic orinformation to indicate what rows are physically adjacent. Withdistributed detection logic, the memory devices themselves can undertakesome of the operations related to identifying hammered rows and thevictim row(s), as well one or more operations related to generating atargeted refresh command.

FIG. 6 is an embodiment of a command truth table supporting a targetedrefresh command. Command truth table 600 represents one example of atruth table for a memory device. In accordance with table 600, oneembodiment of sending a targeted refresh trigger is for the memorycontroller to issues a targeted refresh command (row hammer commandidentified as command 630). In an alternative embodiment, a differentmechanism is used to trigger the memory device to perform a targetedrefresh. The column to the left identifies supported functions. Thecolumns to the right identify the value of different signals to specifythe identified functions.

Of particular note in table 600 for purposes of discussion here iscommand 630, which is Row Hammer command. In one embodiment, prior tosetting command 630 on a C/A bus to the memory device, the memorycontroller places the memory device in a ‘row hammer mode’ via a ModeRegister (MR) bit or bits. In one embodiment, the memory controllerprovides row address along with bank group and bank address to thememory device. The memory device performs a targeted refresh using theaddress provided to the physical row adjacent to the address. Afterallowing a period of time for the refresh command to occur, the memorycontroller can then remove the memory device from ‘row hammer mode’ byresetting the MR bit(s). Thus, when the MR bit is set by the memorycontroller, the memory device understands command 630 as a Row Hammercommand, which could otherwise be understood as a Bank Activate command.

In one embodiment, Row Hammer is identical to Bank Activate (the commandabove it), with the exception of the value of signal 610, ACT_n. Thus,in one embodiment, the Row Hammer command is triggered by ACT_n, whichis a pin or signal not in previous memory standards. The signal on ACT_ncan indicate whether or not the command is Row Hammer or Bank Activate.It is shown as active-low, but could alternatively be configured to beactive-high. Both commands can identify an address, as indicated by therow address bits.

It will be observed that the three columns labeled as 620 include RAS,CAS and WE signals. However, these commands can be controlled internallyby the memory device itself. Thus, by multiplexing these signals withadditional address information (address bits A16, A15, and A14,respectively), enables more address information to be provided to moreparticularly identify the address of the target of the row hammercondition.

When ACT is set (e.g., column 620), the memory device reads RAS/CAS/WEas row address information. When ACT is not set, the memory device readsRAS/CAS/WE as traditional memory access encoding. As mentioned above,the address information could be identified for block, specific row, orsome other size area. The refresh can be as specific or as wide asdesired for the system.

While the Activate command is shown as being doubled up by the use ofsignal ACT_n, Refresh or any other command could be used. Alternatively,a completely new command could be used for targeted refresh. Asillustrated, the targeted refresh command can be said to be embedded inan Activate command. The memory device identifies the victim row basedon the address inside row hammer command 630.

FIG. 7 is a block diagram of an embodiment of a computing system inwhich row hammer monitoring can be implemented. System 700 represents acomputing device in accordance with any embodiment described herein, andcan be a laptop computer, a desktop computer, a server, a gaming orentertainment control system, a scanner, copier, printer, or otherelectronic device. System 700 includes processor 720, which providesprocessing, operation management, and execution of instructions forsystem 700. Processor 720 can include any type of microprocessor,central processing unit (CPU), processing core, or other processinghardware to provide processing for system 700. Processor 720 controlsthe overall operation of system 700, and can be or include, one or moreprogrammable general-purpose or special-purpose microprocessors, digitalsignal processors (DSPs), programmable controllers, application specificintegrated circuits (ASICs), programmable logic devices (PLDs), or thelike, or a combination of such devices.

Memory subsystem 730 represents the main memory of system 700, andprovides temporary storage for code to be executed by processor 720, ordata values to be used in executing a routine. Memory subsystem 730 caninclude one or more memory devices such as read-only memory (ROM), flashmemory, one or more varieties of random access memory (RAM), or othermemory devices, or a combination of such devices. Memory subsystem 730stores and hosts, among other things, operating system (OS) 736 toprovide a software platform for execution of instructions in system 700.Additionally, other instructions 738 are stored and executed from memorysubsystem 730 to provide the logic and the processing of system 700. OS736 and instructions 738 are executed by processor 720.

Memory subsystem 730 includes memory device 732 where it stores data,instructions, programs, or other items. In one embodiment, memorysubsystem includes memory controller 734, which is a memory controllerin accordance with any embodiment described herein, and which provides atargeted refresh command to memory device 732 based on a row hammercondition. A row hammer condition can be detected based on a thresholdstored for the memory device, in accordance with any embodimentdescribed herein. The targeted refresh command causes memory device 732to perform a targeted refresh, which is a refresh operation off-cycle,meaning it is not on the regularly scheduled cycle of refreshes, and isnot necessarily on an area tracked by the memory device as the next areato refresh. Rather, the region refreshed is based on a victim row orregion identified based on an address associated with the targetedrefresh command(s). Memory controller 734 can trigger a targeted refreshin memory 732 in response to detection by distributed detection logic inaccordance with any embodiment described herein.

Processor 720 and memory subsystem 730 are coupled to bus/bus system710. Bus 710 is an abstraction that represents any one or more separatephysical buses, communication lines/interfaces, and/or point-to-pointconnections, connected by appropriate bridges, adapters, and/orcontrollers. Therefore, bus 710 can include, for example, one or more ofa system bus, a Peripheral Component Interconnect (PCI) bus, aHyperTransport or industry standard architecture (ISA) bus, a smallcomputer system interface (SCSI) bus, a universal serial bus (USB), oran Institute of Electrical and Electronics Engineers (IEEE) standard1394 bus (commonly referred to as “Firewire”). The buses of bus 710 canalso correspond to interfaces in network interface 750.

System 700 also includes one or more input/output (I/O) interface(s)740, network interface 750, one or more internal mass storage device(s)760, and peripheral interface 770 coupled to bus 710. I/O interface 740can include one or more interface components through which a userinteracts with system 700 (e.g., video, audio, and/or alphanumericinterfacing). Network interface 750 provides system 700 the ability tocommunicate with remote devices (e.g., servers, other computing devices)over one or more networks. Network interface 750 can include an Ethernetadapter, wireless interconnection components, USB (universal serialbus), or other wired or wireless standards-based or proprietaryinterfaces.

Storage 760 can be or include any conventional medium for storing largeamounts of data in a nonvolatile manner, such as one or more magnetic,solid state, or optical based disks, or a combination. Storage 760 holdscode or instructions and data 762 in a persistent state (i.e., the valueis retained despite interruption of power to system 700). Storage 760can be generically considered to be a “memory,” although memory 730 isthe executing or operating memory to provide instructions to processor720. Whereas storage 760 is nonvolatile, memory 730 can include volatilememory (i.e., the value or state of the data is indeterminate if poweris interrupted to system 700).

Peripheral interface 770 can include any hardware interface notspecifically mentioned above. Peripherals refer generally to devicesthat connect dependently to system 700. A dependent connection is onewhere system 700 provides the software and/or hardware platform on whichoperation executes, and with which a user interacts.

FIG. 8 is a block diagram of an embodiment of a mobile device in whichrow hammer monitoring can be implemented. Device 800 represents a mobilecomputing device, such as a computing tablet, a mobile phone orsmartphone, a wireless-enabled e-reader, or other mobile device. It willbe understood that certain of the components are shown generally, andnot all components of such a device are shown in device 800.

Device 800 includes processor 810, which performs the primary processingoperations of device 800. Processor 810 can include one or more physicaldevices, such as microprocessors, application processors,microcontrollers, programmable logic devices, or other processing means.In one embodiment, processor 810 includes optical interface componentsin addition to a processor die. Thus, the processor die and photoniccomponents are in the same package. Such a processor package caninterface optically with an optical connector in accordance with anyembodiment described herein.

The processing operations performed by processor 810 include theexecution of an operating platform or operating system on whichapplications and/or device functions are executed. The processingoperations include operations related to I/O (input/output) with a humanuser or with other devices, operations related to power management,and/or operations related to connecting device 800 to another device.The processing operations can also include operations related to audioI/O and/or display I/O.

In one embodiment, device 800 includes audio subsystem 820, whichrepresents hardware (e.g., audio hardware and audio circuits) andsoftware (e.g., drivers, codecs) components associated with providingaudio functions to the computing device. Audio functions can includespeaker and/or headphone output, as well as microphone input. Devicesfor such functions can be integrated into device 800, or connected todevice 800. In one embodiment, a user interacts with device 800 byproviding audio commands that are received and processed by processor810.

Display subsystem 830 represents hardware (e.g., display devices) andsoftware (e.g., drivers) components that provide a visual and/or tactiledisplay for a user to interact with the computing device. Displaysubsystem 830 includes display interface 832, which includes theparticular screen or hardware device used to provide a display to auser. In one embodiment, display interface 832 includes logic separatefrom processor 810 to perform at least some processing related to thedisplay. In one embodiment, display subsystem 830 includes a touchscreendevice that provides both output and input to a user.

I/O controller 840 represents hardware devices and software componentsrelated to interaction with a user. I/O controller 840 can operate tomanage hardware that is part of audio subsystem 820 and/or displaysubsystem 830. Additionally, I/O controller 840 illustrates a connectionpoint for additional devices that connect to device 800 through which auser might interact with the system. For example, devices that can beattached to device 800 might include microphone devices, speaker orstereo systems, video systems or other display device, keyboard orkeypad devices, or other I/O devices for use with specific applicationssuch as card readers or other devices.

As mentioned above, I/O controller 840 can interact with audio subsystem820 and/or display subsystem 830. For example, input through amicrophone or other audio device can provide input or commands for oneor more applications or functions of device 800. Additionally, audiooutput can be provided instead of or in addition to display output. Inanother example, if display subsystem includes a touchscreen, thedisplay device also acts as an input device, which can be at leastpartially managed by I/O controller 840. There can also be additionalbuttons or switches on device 800 to provide I/O functions managed byI/O controller 840.

In one embodiment, I/O controller 840 manages devices such asaccelerometers, cameras, light sensors or other environmental sensors,gyroscopes, global positioning system (GPS), or other hardware that canbe included in device 800. The input can be part of direct userinteraction, as well as providing environmental input to the system toinfluence its operations (such as filtering for noise, adjustingdisplays for brightness detection, applying a flash for a camera, orother features).

In one embodiment, device 800 includes power management 850 that managesbattery power usage, charging of the battery, and features related topower saving operation. Memory subsystem 860 includes memory device(s)862 for storing information in device 800. Memory subsystem 860 caninclude nonvolatile (state does not change if power to the memory deviceis interrupted) and/or volatile (state is indeterminate if power to thememory device is interrupted) memory devices. Memory 860 can storeapplication data, user data, music, photos, documents, or other data, aswell as system data (whether long-term or temporary) related to theexecution of the applications and functions of system 800.

In one embodiment, memory subsystem 860 includes memory controller 864(which could also be considered part of the control of system 800, andcould potentially be considered part of processor 810). Memorycontroller 864 issues a targeted refresh command based on a row hammercondition at a specific row of memory of memory device 862. Memorycontroller 864 can detect the row hammer condition based on a thresholdstored for the memory device, in accordance with any embodimentdescribed herein. Memory controller 864 can trigger a targeted refreshin memory 832 in response to detection by distributed detection logic inaccordance with any embodiment described herein.

Connectivity 870 includes hardware devices (e.g., wireless and/or wiredconnectors and communication hardware) and software components (e.g.,drivers, protocol stacks) to enable device 800 to communicate withexternal devices. The device could be separate devices, such as othercomputing devices, wireless access points or base stations, as well asperipherals such as headsets, printers, or other devices.

Connectivity 870 can include multiple different types of connectivity.To generalize, device 800 is illustrated with cellular connectivity 872and wireless connectivity 874. Cellular connectivity 872 refersgenerally to cellular network connectivity provided by wirelesscarriers, such as provided via GSM (global system for mobilecommunications) or variations or derivatives, CDMA (code divisionmultiple access) or variations or derivatives, TDM (time divisionmultiplexing) or variations or derivatives, LTE (long termevolution—also referred to as “4G”), or other cellular servicestandards. Wireless connectivity 874 refers to wireless connectivitythat is not cellular, and can include personal area networks (such asBluetooth), local area networks (such as WiFi), and/or wide areanetworks (such as WiMax), or other wireless communication. Wirelesscommunication refers to transfer of data through the use of modulatedelectromagnetic radiation through a non-solid medium. Wiredcommunication occurs through a solid communication medium.

Peripheral connections 880 include hardware interfaces and connectors,as well as software components (e.g., drivers, protocol stacks) to makeperipheral connections. It will be understood that device 800 could bothbe a peripheral device (“to” 882) to other computing devices, as well ashave peripheral devices (“from” 884) connected to it. Device 800commonly has a “docking” connector to connect to other computing devicesfor purposes such as managing (e.g., downloading and/or uploading,changing, synchronizing) content on device 800. Additionally, a dockingconnector can allow device 800 to connect to certain peripherals thatallow device 800 to control content output, for example, to audiovisualor other systems.

In addition to a proprietary docking connector or other proprietaryconnection hardware, device 800 can make peripheral connections 880 viacommon or standards-based connectors. Common types can include aUniversal Serial Bus (USB) connector (which can include any of a numberof different hardware interfaces), DisplayPort including MiniDisplayPort(MDP), High Definition Multimedia Interface (HDMI), Firewire, or othertype.

In one aspect, a memory subsystem includes a memory device havingmultiple physical rows of memory cells; and row hammer detection logiccoupled to the memory device, the detection logic to obtain an accessrate threshold for the memory device from a register that storesconfiguration information for the memory device, the thresholdidentifying a number of accesses to a specific row of memory within atime window that causes risk of data corruption on a row physicallyadjacent to the accessed row; determine based on the threshold whether anumber of accesses to one of the multiple physical rows of the memorydevice exceeds the threshold; and in response to detecting that thenumber of accesses exceeds the threshold, trigger the memory device toperform a refresh targeted to a victim row physically adjacent to therow for which the number of accesses exceeded the threshold.

In one embodiment, the row hammer detection logic comprises detectionlogic of a memory controller coupled to the memory device. In oneembodiment, the row hammer detection logic comprises distributeddetection logic of the memory device. In one embodiment, the registerthat stores configuration information for the memory device comprises aconfiguration storage device of a memory module of which the memorydevice is a part. In one embodiment, the register that storesconfiguration information for the memory device comprises aconfiguration register on the memory device. In one embodiment, thedetection logic is to obtain a three-bit code that indicates thethreshold.

In one embodiment, the threshold for the memory device is a firstthreshold, and is different from a second threshold for a differentmemory device in the memory subsystem. In one embodiment, the detectionlogic monitors each memory device in accordance with its differentthreshold. In one embodiment, the detection logic is to furtherdetermine which threshold is lower; and monitor the memory devices inaccordance with the lower threshold.

In one aspect, an electronic device includes a memory subsystem having amemory device having multiple physical rows of memory cells; and rowhammer detection logic coupled to the memory device, the detection logicto obtain an access rate threshold for the memory device from a registerthat stores configuration information for the memory device, thethreshold identifying a number of accesses to a specific row of memorywithin a time window that causes risk of data corruption on a rowphysically adjacent to the accessed row; determine based on thethreshold whether a number of accesses to one of the multiple physicalrows of the memory device exceeds the threshold; and in response todetecting that the number of accesses exceeds the threshold, trigger thememory device to perform a refresh targeted to a victim row physicallyadjacent to the row for which the number of accesses exceeded thethreshold; and a touchscreen display device configured to provide a userdisplay based on data accessed from the memory device.

In one embodiment, the register that stores configuration informationfor the memory device comprises a configuration storage device of amemory module of which the memory device is a part. In one embodiment,the register that stores configuration information for the memory devicecomprises a configuration register on the memory device. In oneembodiment, the threshold for the memory device is a first threshold,and is different from a second threshold for a different memory devicein the memory subsystem. In one embodiment, the detection logic monitorseach memory device in accordance with its different threshold. In oneembodiment, the detection logic is to further determine which thresholdis lower; and monitor the memory devices in accordance with the lowerthreshold. In one embodiment, the detection logic is to obtain a fieldof a configuration register that stores a code indicating the threshold.

In one aspect, a method includes obtaining an access rate threshold fora memory device from a register that stores configuration informationfor the memory device, the threshold identifying a number of accesses toa specific row of memory within a time window that causes risk of datacorruption on a row physically adjacent to the accessed row; determiningbased on the threshold whether a number of accesses to one of themultiple physical rows of the memory device exceeds the threshold; andin response to detecting that the number of accesses exceeds thethreshold, generating a trigger to cause the memory device to perform arefresh targeted to a victim row physically adjacent to the row forwhich the number of accesses exceeded the threshold.

In one embodiment, generating the trigger comprises sending an alertfrom distributed detection logic at the memory device to a memorycontroller to cause the memory controller to issue a targeted refreshcommand to the memory device. In one embodiment, determining whether thenumber of access exceeds the threshold further comprises: monitoringaccesses to rows of the memory device for the time window; determiningif a number of accesses for any of the rows exceeds the threshold; andindicating address information for a row determined to exceed the numberof accesses in the time window. In one embodiment, the threshold for thememory device is a first threshold, different from a second thresholdfor a different memory device sharing a memory subsystem with the memorydevice, and wherein determining based on the threshold furthercomprises: determining whether the first or second threshold is lower;and monitoring both memory devices based on the determined lowerthreshold.

Flow diagrams as illustrated herein provide examples of sequences ofvarious process actions. Although shown in a particular sequence ororder, unless otherwise specified, the order of the actions can bemodified. Thus, the illustrated embodiments should be understood only asan example, and the process can be performed in a different order, andsome actions can be performed in parallel. Additionally, one or moreactions can be omitted in various embodiments; thus, not all actions arerequired in every embodiment. Other process flows are possible.

To the extent various operations or functions are described herein, theycan be described or defined as software code, instructions,configuration, and/or data. The content can be directly executable(“object” or “executable” form), source code, or difference code(“delta” or “patch” code). The software content of the embodimentsdescribed herein can be provided via an article of manufacture with thecontent stored thereon, or via a method of operating a communicationinterface to send data via the communication interface. A machinereadable storage medium can cause a machine to perform the functions oroperations described, and includes any mechanism that stores informationin a form accessible by a machine (e.g., computing device, electronicsystem, etc.), such as recordable/non-recordable media (e.g., read onlymemory (ROM), random access memory (RAM), magnetic disk storage media,optical storage media, flash memory devices, etc.). A communicationinterface includes any mechanism that interfaces to any of a hardwired,wireless, optical, etc., medium to communicate to another device, suchas a memory bus interface, a processor bus interface, an Internetconnection, a disk controller, etc. The communication interface can beconfigured by providing configuration parameters and/or sending signalsto prepare the communication interface to provide a data signaldescribing the software content. The communication interface can beaccessed via one or more commands or signals sent to the communicationinterface.

Various components described herein can be a means for performing theoperations or functions described. Each component described hereinincludes software, hardware, or a combination of these. The componentscan be implemented as software modules, hardware modules,special-purpose hardware (e.g., application specific hardware,application specific integrated circuits (ASICs), digital signalprocessors (DSPs), etc.), embedded controllers, hardwired circuitry,etc.

Besides what is described herein, various modifications can be made tothe disclosed embodiments and implementations of the invention withoutdeparting from their scope. Therefore, the illustrations and examplesherein should be construed in an illustrative, and not a restrictivesense. The scope of the invention should be measured solely by referenceto the claims that follow.

What is claimed is:
 1. A memory subsystem comprising: a memory devicehaving multiple physical rows of memory cells; and detection logiccoupled to the memory device, the detection logic to obtain an accessrate threshold for the memory device from a register that storesconfiguration information for the memory device, the thresholdidentifying a number of accesses to a specific row of memory within atime window that causes risk of data corruption on a row physicallyadjacent to the accessed row; determine based on the threshold whether anumber of accesses to one of the multiple physical rows of the memorydevice exceeds the threshold; and in response to detecting that thenumber of accesses exceeds the threshold, trigger the memory device toperform a refresh targeted to a victim row physically adjacent to therow for which the number of accesses exceeded the threshold.
 2. Thememory subsystem of claim 1, wherein the detection logic comprisesdetection logic of a memory controller coupled to the memory device. 3.The memory subsystem of claim 1, wherein the detection logic comprisesdistributed detection logic of the memory device.
 4. The memorysubsystem of claim 1, wherein the register that stores configurationinformation for the memory device comprises a configuration storagedevice of a memory module of which the memory device is a part.
 5. Thememory subsystem of claim 1, wherein the register that storesconfiguration information for the memory device comprises aconfiguration register on the memory device.
 6. The memory subsystem ofclaim 1, wherein the detection logic is to obtain a three-bit code thatindicates the threshold.
 7. The memory subsystem of claim 1, wherein thethreshold for the memory device is a first threshold, and is differentfrom a second threshold for a different memory device in the memorysubsystem.
 8. The memory subsystem of claim 7, wherein the detectionlogic monitors each memory device in accordance with its differentthreshold.
 9. The memory subsystem of claim 7, wherein the detectionlogic is to further determine which threshold is lower; and monitor thememory devices in accordance with the lower threshold.
 10. An electronicdevice comprising: a memory subsystem having a memory device havingmultiple physical rows of memory cells; and detection logic coupled tothe memory device, the detection logic to obtain an access ratethreshold for the memory device from a register that storesconfiguration information for the memory device, the thresholdidentifying a number of accesses to a specific row of memory within atime window that causes risk of data corruption on a row physicallyadjacent to the accessed row; determine based on the threshold whether anumber of accesses to one of the multiple physical rows of the memorydevice exceeds the threshold; and in response to detecting that thenumber of accesses exceeds the threshold, trigger the memory device toperform a refresh targeted to a victim row physically adjacent to therow for which the number of accesses exceeded the threshold; and atouchscreen display device configured to provide a user display based ondata accessed from the memory device.
 11. The electronic device of claim10, wherein the register that stores configuration information for thememory device comprises a configuration storage device of a memorymodule of which the memory device is a part.
 12. The electronic deviceof claim 10, wherein the register that stores configuration informationfor the memory device comprises a configuration register on the memorydevice.
 13. The electronic device of claim 10, wherein the threshold forthe memory device is a first threshold, and is different from a secondthreshold for a different memory device in the memory subsystem.
 14. Theelectronic device of claim 13, wherein the detection logic monitors eachmemory device in accordance with its different threshold.
 15. Theelectronic device of claim 13, wherein the detection logic is to furtherdetermine which threshold is lower; and monitor the memory devices inaccordance with the lower threshold.
 16. The electronic device of claim10, wherein the detection logic is to obtain a field of a configurationregister that stores a code indicating the threshold.
 17. A methodcomprising: obtaining an access rate threshold for a memory device froma register that stores configuration information for the memory device,the threshold identifying a number of accesses to a specific row ofmemory within a time window that causes risk of data corruption on a rowphysically adjacent to the accessed row; determining based on thethreshold whether a number of accesses to one of the multiple physicalrows of the memory device exceeds the threshold; and in response todetecting that the number of accesses exceeds the threshold, generatinga trigger to cause the memory device to perform a refresh targeted to avictim row physically adjacent to the row for which the number ofaccesses exceeded the threshold.
 18. The method of claim 17, whereingenerating the trigger comprises sending an alert from distributeddetection logic at the memory device to a memory controller to cause thememory controller to issue a targeted refresh command to the memorydevice.
 19. The method of claim 17, wherein determining whether thenumber of access exceeds the threshold further comprises: monitoringaccesses to rows of the memory device for the time window; determiningif a number of accesses for any of the rows exceeds the threshold; andindicating address information for a row determined to exceed the numberof accesses in the time window.
 20. The method of claim 17, wherein thethreshold for the memory device is a first threshold, different from asecond threshold for a different memory device sharing a memorysubsystem with the memory device, and wherein determining based on thethreshold further comprises: determining whether the first or secondthreshold is lower; and monitoring both memory devices based on thedetermined lower threshold.
 21. A memory subsystem comprising: a memorydevice having multiple physical rows of memory cells; and a memorycontroller device coupled to the memory device, the memory controllerdevice configured to obtain a programmable access rate threshold for thememory device from a register that stores configuration information forthe memory device, the threshold identifying a number of accesses to aspecific row of memory within a time window that causes risk of datacorruption on a row physically adjacent to the accessed row, thethreshold dynamically programmable; configured to determine that anumber of accesses to one of the multiple physical rows of the memorydevice exceeds the threshold; and configured to trigger the memorydevice to perform a refresh targeted for a victim row physicallyadjacent to the row for which the number of accesses exceeded thethreshold, in response to determining that the number of access exceedsthe threshold.
 22. The memory subsystem of claim 21, wherein the memorycontroller further comprises a memory with a table to store a count forrows that experience repeated access.
 23. The memory subsystem of claim22, wherein the table includes a number of rows based on a maximumvictim count for the time window.